Jordan Terrell will be speaking on Domain Driven Design tomorrow, October 1, 2009.

There is no article in the Architect Column this month. I am very busy working on applications scheduled to go live in October. Thank you for your understanding and thank you for reading our blog!

Ksenia Symonova is a recent winner of the Ukraine’s Got Talent show. You might think that she is a singer or a dancer, but that is far from the actual case. She is a sand artist.

Take a look at a couple of videos below. They are amazing.

• http://www.youtube.com/watch?v=518XP8prwZo
• http://www.youtube.com/watch?v=xzfX7hsKY3Y

Hamlet D'Arcy will be speaking on Thinking in Functions this coming Tuesday, Sep 15, 2009.

See more information at http://www.otug.org.

Martin Fowler
Patterns of Enterprise Application Architecture

This book catalogs a collection of design patterns commonly used when writing business applications:

• Domain Logic
  Transaction Script, Table Module, Domain Model, Service Layer
• Data Source
  Table Data Gateway, Row Data Gateway, Active Record, Data Mapper
• Object-Relational Behavioral
  Unit of Work, Identity Map, Lazy Load
• Object-Relational Structural
  Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Mapping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance, Inheritance Mappers
• Object-Relational Metadata Mapping
  Metadata Mapping, Query Object, Repository
• Web Presentation
  Model View Controller, Page Controller, Front Controller, Template View, Transform View, Two Step View, Application Controller
• Distribution
  Remote Facade, Data Transfer Object
• Concurrence
  Optimistic Offline Lock, Pessimistic Offline Lock, Coarse-Grained Lock
• Session State
  Client Session State, Server Session State, Database Session State
• Miscellaneous
  Gateway, Mapper, Layer Supertype, Separate Interface, Registry, Value Object, Money, Special Case, Plug-in, Service Stub, Record Set

Many of these patterns are available as frameworks and you do not need to implement them from scratch. As a side effect, the frameworks, such as O/R mapping and web presentation tools, have a tendency to hide their implementation techniques. The patterns cataloged and described by Martin Fowler will help you understand what happens behind the scene and and use this knowledge for optimizing, troubleshooting, and improving the design of your applications.

This book has something valuable for everybody. If you are new to the industry, you will learn about common recurring problems building enterprise applications and study techniques to solve them. If you used these patterns before, you will deepen your understanding of them.

Click here to find out more about this book. Happy reading!

This is a remarkable presentation by Seth Godin on marketing.

Seth gave this talk at the Business of Software conference last year. It is about one hour long, full of interesting examples and ideas. Enjoy!

Problem Statement

Last month, I blogged about organizing code in a source control system. We looked at how release units help us represent a domain context map to support domain-driven design and distributed application development. We recommended adopting a standard release unit layout so that your release process can be clearly understood and automated.

This month, we will take a deep dive into the release unit's trunk folder. I said before that trunk contains the latest version of the release unit code. How shall we organize our code inside trunk?

Objectives

As always, let's define our objectives:

• Support domain-driven design philosophy
• Support principles of object-oriented design
• Support distributed application development
• Support a structured, repeatable, and traceable release process

Release Units in .NET

Release Unit is a collection of folders and files that are released together. In .NET environment, this is achieved with a .NET solution that groups multiple projects together for the purposes of debug, compilation, and release. Hence, if you are working in .NET environment:

Each release unit should contain one and only one .NET solution.

.NET Solution Structure

Now, we are ready to take a look at a sample .NET solution structure that will help you implement principles of domain-driven design and object-oriented programming. For simplicity, let's assume our solution consists of a single web application and a command-line data setup utility. You will have no problems extending this approach to handle your own more sophisticated scenarios.

/doc - contains release unit's documentation.

/lib - contains release unit's pull dependencies. When your project uses a .NET assembly not part of your solution, place the assembly into the lib folder and reference it from there. It ensures that all projects in the same solution always use the same version of the dependent upon library and provides you with a clear way to upgrade the library to a new version should you decide to do so.

/Database - contains database creation and modification scripts, scripts to set up users and their permissions, load data files, etc. This folder may also include command-line batch files to set up the release unit on a local machine, build, integration or test server.

/Model - contains classes of the Domain Model, a central part of the release unit. This assembly describes what can be accomplished by the release unit in business terms. Keep the model free from infrastructural detail. It will help you achieve high levels of reuse and low costs of maintenance in your applications. Next month, we will take a look at how to organize your domain model to clearly identify all supported business scenarios and transactions. This is a big topic on its own, which certainly deserves a dedicated blog article.

/ModelUT - contains unit tests for the Domain Model classes.

/Persistence - implements a persistence mechanism for the release unit's domain model. I strongly recommend keeping persistence interfaces with the model itself since it shows how aggregates and entities are designed to be loaded into memory. The purpose of the persistence library is to implement persistence interfaces with your standard tools and techniques.

/PersistenceUT - contains configuration files and unit tests for the Persistence. In our case, these tests verify the release unit's persistence classes and their configuration files as well as the database. Strictly speaking, they are integration tests. However for the purposes of the domain modeling, we prefer to think about the whole domian model persistence as a black box.

/WebInfrastructure - contains web infrastructural classes which would otherwise be placed in the App_Code directory on the web site. Extracting these classes into a dedicated library allows them to be unit tested.

/WebInfrastructureUT - contains unit tests for the web infrastructural components.

/Web - contains a web application, a top application layer responsible not only for user interface but also for referencing and configuring all its depencies.

/WebUAT - contains user acceptance test scripts, such as Selenium or WatiN.

/WebLT - contains load testing projects, such as JMeter or LoadRunner.

/DataSetup - contains a command-line process to perform backroom administrative tasks.

/DataSetupUT - contains unit tests for the data setup components.

Dependencies

To better understand this sample solution structure, take a look at the package diagram below:

Summary

1. For each release unit, create a .NET solution file.
2. Place all of your external pull dependencies into the lib folder.
3. Keep your model classes free from any infrastructural detail.
4. Make your top layer responsible for connecting and configuring all its dependencies.

Happy coding!

Based on the comments received, I have updated my last month's article in the Architect column. In the end of the article, you will now find a 5-step summary on how to structure your source control repository in order to support:

• Domain-driven design philosophy
• Distributed application development
• Structured, repeatable, and traceable release process

Thank you for reading Modelus Blog!

No RSVP is need. See more information on otug.org.

Patrick Lencioni
The Five Dysfunctions of a Team

Katheryn Petersen is put in charge of DecisionTech, a young promising 150-people Silicon Valley start-up, experiencing a series of disappointments: slipped deadlines, lost key employees, and deteriorated morale. With no high-tech experience and a limited political capital with the board, she does not seem to fit DecisionTech's corporate culture.

After interviewing members of the board and spending time with her executives, Katheryn realizes that they do not function as a cohesive unit. She dedicates her time, energy, and effort to addressing the issues preventing her executive team from reaching its full potential.

Katheryn introduces her executives to a teamwork development model and teaches them how to overcome team dysfunctions:

1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to Results

Will Katheryn be able to turn things around? Can she meet the revenue goals and dramatically increase the sales? Read this exciting and thought-provoking business novel to find out!

To find out more information about this book, click here. Happy reading!